Autogenerated HTML docs for v1.5.0.3-310-g05ef5
diff --git a/git-receive-pack.html b/git-receive-pack.html index 6c73b5d..d02c4ac 100644 --- a/git-receive-pack.html +++ b/git-receive-pack.html
@@ -286,55 +286,11 @@ (heads/tags) on the remote end (strictly speaking, it is the local end receive-pack runs, but to the user who is sitting at the send-pack end, it is updating the remote. Confused?)</p> -<p>Before each ref is updated, if $GIT_DIR/hooks/update file exists -and executable, it is called with three parameters:</p> -<div class="literalblock"> -<div class="content"> -<pre><tt>$GIT_DIR/hooks/update refname sha1-old sha1-new</tt></pre> -</div></div> -<p>The refname parameter is relative to $GIT_DIR; e.g. for the -master head this is "refs/heads/master". Two sha1 are the -object names for the refname before and after the update. Note -that the hook is called before the refname is updated, so either -should match what is recorded in refname.</p> -<p>The hook should exit with non-zero status if it wants to -disallow updating the named ref. Otherwise it should exit with -zero.</p> -<p>Using this hook, it is easy to generate mails on updates to -the local repository. This example script sends a mail with -the commits pushed to the repository:</p> -<div class="literalblock"> -<div class="content"> -<pre><tt>#!/bin/sh -# mail out commit update information. -if expr "$2" : '0*$' >/dev/null -then - echo "Created a new ref, with the following commits:" - git-rev-list --pretty "$2" -else - echo "New commits:" - git-rev-list --pretty "$3" "^$2" -fi | -mail -s "Changes to ref $1" commit-list@mydomain -exit 0</tt></pre> -</div></div> -<p>Another hook $GIT_DIR/hooks/post-update, if exists and -executable, is called with the list of refs that have been -updated. This can be used to implement repository wide cleanup -task if needed. The exit code from this hook invocation is -ignored; the only thing left for git-receive-pack to do at that -point is to exit itself anyway. This hook can be used, for -example, to run "git-update-server-info" if the repository is -packed and is served via a dumb transport.</p> -<div class="literalblock"> -<div class="content"> -<pre><tt>#!/bin/sh -exec git-update-server-info</tt></pre> -</div></div> <p>There are other real-world examples of using update and post-update hooks found in the Documentation/howto directory.</p> -<p>git-receive-pack honours the receive.denyNonFastforwards flag, which -tells it if updates to a ref should be denied if they are not fast-forwards.</p> +<p>git-receive-pack honours the receive.denyNonFastForwards config +option, which tells it if updates to a ref should be denied if they +are not fast-forwards.</p> </div> <h2>OPTIONS</h2> <div class="sectionbody"> @@ -349,6 +305,108 @@ </dd> </dl> </div> +<h2>pre-receive Hook</h2> +<div class="sectionbody"> +<p>Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists +and is executable, it will be invoked once, with three parameters +per ref to be updated:</p> +<div class="literalblock"> +<div class="content"> +<pre><tt>$GIT_DIR/hooks/pre-receive (refname sha1-old sha1-new)+</tt></pre> +</div></div> +<p>The refname parameter is relative to $GIT_DIR; e.g. for the master +head this is "refs/heads/master". The two sha1 arguments after +each refname are the object names for the refname before and after +sha1-old and sha1-new should be valid objects in the repository.</p> +<p>This hook is called before any refname is updated and before any +fast-forward checks are performed.</p> +<p>If the pre-receive hook exits with a non-zero exit status no updates +will be performed, and the update, post-receive and post-update +hooks will not be invoked either. This can be useful to quickly +bail out if the update is not to be supported.</p> +</div> +<h2>update Hook</h2> +<div class="sectionbody"> +<p>Before each ref is updated, if $GIT_DIR/hooks/update file exists +and is executable, it is invoked once per ref, with three parameters:</p> +<div class="literalblock"> +<div class="content"> +<pre><tt>$GIT_DIR/hooks/update refname sha1-old sha1-new</tt></pre> +</div></div> +<p>The refname parameter is relative to $GIT_DIR; e.g. for the master +head this is "refs/heads/master". The two sha1 arguments are +the object names for the refname before and after the update. +Note that the hook is called before the refname is updated, +or it should match what is recorded in refname.</p> +<p>The hook should exit with non-zero status if it wants to disallow +updating the named ref. Otherwise it should exit with zero.</p> +<p>Successful execution (a zero exit status) of this hook does not +ensure the ref will actully be updated, it is only a prerequisite. +As such it is not a good idea to send notices (e.g. email) from +this hook. Consider using the post-receive hook instead.</p> +</div> +<h2>post-receive Hook</h2> +<div class="sectionbody"> +<p>After all refs were updated (or attempted to be updated), if any +ref update was successful, and if $GIT_DIR/hooks/post-receive +file exists and is executable, it will be invoke once with three +parameters for each successfully updated ref:</p> +<div class="literalblock"> +<div class="content"> +<pre><tt>$GIT_DIR/hooks/post-receive (refname sha1-old sha1-new)+</tt></pre> +</div></div> +<p>The refname parameter is relative to $GIT_DIR; e.g. for the master +head this is "refs/heads/master". The two sha1 arguments after +each refname are the object names for the refname before and after +the update. Refs that were created will have sha1-old equal to +the repository.</p> +<p>Using this hook, it is easy to generate mails describing the updates +to the repository. This example script sends one mail message per +ref listing the commits pushed to the repository:</p> +<div class="literalblock"> +<div class="content"> +<pre><tt>#!/bin/sh +# mail out commit update information. +while test $# -gt 0 +do + if expr "$2" : '0*$' >/dev/null + then + echo "Created a new ref, with the following commits:" + git-rev-list --pretty "$2" + else + echo "New commits:" + git-rev-list --pretty "$3" "^$2" + fi | + mail -s "Changes to ref $1" commit-list@mydomain + shift; shift; shift; # discard this ref's args +done +exit 0</tt></pre> +</div></div> +<p>The exit code from this hook invocation is ignored, however a +non-zero exit code will generate an error message.</p> +<p>Note that it is possible for refname to not have sha1-new when this +hook runs. This can easily occur if another user modifies the ref +after it was updated by receive-pack, but before the hook was able +to evaluate it. It is recommended that hooks rely on sha1-new +rather than the current value of refname.</p> +</div> +<h2>post-update Hook</h2> +<div class="sectionbody"> +<p>After all other processing, if at least one ref was updated, and +if $GIT_DIR/hooks/post-update file exists and is executable, then +post-update will called with the list of refs that have been updated. +This can be used to implement any repository wide cleanup tasks.</p> +<p>The exit code from this hook invocation is ignored; the only thing +left for git-receive-pack to do at that point is to exit itself +anyway.</p> +<p>This hook can be used, for example, to run "git-update-server-info" +if the repository is packed and is served via a dumb transport.</p> +<div class="literalblock"> +<div class="content"> +<pre><tt>#!/bin/sh +exec git-update-server-info</tt></pre> +</div></div> +</div> <h2>SEE ALSO</h2> <div class="sectionbody"> <p><a href="git-send-pack.html">git-send-pack(1)</a></p> @@ -367,7 +425,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 19-Jan-2007 00:37:30 UTC +Last updated 08-Mar-2007 02:42:38 UTC </div> </div> </body>
